Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/taskito-java/src/workflows/mod.rs`:
- Around line 230-232: The workflow reuse path in mod.rs is only checking same
DAG name/version, but `StepMetadata` fields like `condition`, `gate`, and
`sub_workflow` can change execution behavior and must be part of compatibility.
Update the existing-definition lookup in the workflow step handling code to
compare `step_meta` as well, or reject reuse and require a version bump when the
metadata differs. Use the `StepMetadata`/step reuse logic around the
`condition`, `gate`, and `sub_workflow` assignment to locate the compatibility
check and ensure stale metadata cannot be reused.
- Around line 588-610: `workflowNameForRun` currently returns only `def.name`,
which can collide across workflow versions and make deferred payload resolution
pick the wrong workflow. Update
`Java_org_byteveda_taskito_internal_NativeWorkflows_workflowNameForRun` and the
related tracker path to expose a versioned workflow identity, or add a separate
version accessor, and ensure the Java tracker caches deferred payloads using
both workflow name and version. Use the existing `wf.get_workflow_run(...)` and
`get_workflow_definition_by_id(...)` lookup flow to retrieve the version
alongside the name and return/store both fields consistently.
- Around line 1050-1055: The node is still being marked Skipped in the workflow
update flow even when queue.storage.cancel_job fails, which can leave a running
bound job behind. In the workflow handling around wf.get_workflow_node, capture
and propagate the cancel_job result instead of discarding it, or only suppress
explicitly safe cases like already terminal/not found, and only call
wf.update_workflow_node_status to Skipped after cancellation has succeeded.

In `@sdks/java/src/main/java/org/byteveda/taskito/DefaultTaskito.java`:
- Around line 459-460: The workflow definition reuse logic is too permissive:
`DefaultTaskito` only compares DAG topology, so changes to behavior-bearing gate
metadata can be ignored and stale `StepMetadata.gate` may be reused. Update the
definition compatibility check in the native submit path to include step
metadata (especially gate fields encoded via `encodeGate`), or explicitly reject
resubmits under the same version when metadata drifts. Make sure the stored
definition used later by the tracker cannot silently carry over old gate
timeout/action/message settings.

In `@sdks/java/src/main/java/org/byteveda/taskito/workflows/GateConfig.java`:
- Around line 30-37: Reject null in the GateConfig.timeout factory methods: both
timeout(Duration, GateAction) and timeout(Duration, GateAction, String) should
validate that the timeout argument is non-null instead of passing it through to
the record constructor, since GateConfig currently treats a null timeout as an
indefinite manual gate. Add an explicit null check or equivalent validation in
these timeout overloads so misconfigured auto-resolution paths fail fast rather
than creating a wait-forever gate.

In `@sdks/java/src/main/java/org/byteveda/taskito/workflows/Step.java`:
- Around line 120-136: The public Step.Builder.gate(...) setter is allowing
normal task steps to be marked as gates, but the workflow execution path treats
any step with gate != null as a deferred control node and skips enqueuing its
task payload. Update Step.Builder.build() and related gate validation so gates
are only allowed on Workflow.gate(...) / __gate__ control nodes, or otherwise
change the execution/tracking flow to enqueue the task after approval; use the
Step.Builder.gate(...) and Step.build() symbols to locate the fix.

In `@sdks/java/src/main/java/org/byteveda/taskito/workflows/Workflow.java`:
- Around line 82-90: The gate path in Workflow.gate currently leaves downstream
deferred nodes vulnerable to the getWorkflowPlan queue-default gap, so
WorkflowTracker can recreate them on "default" instead of the intended lane.
Update the gate/deferred-node handling in Workflow.gate and the related workflow
plan generation so the run default queue is propagated for deferred successors,
or enforce/fail fast when a deferred step lacks an explicit .queue(...) and
document that requirement clearly in the gate API behavior.

In `@sdks/java/src/main/java/org/byteveda/taskito/workflows/WorkflowTracker.java`:
- Around line 253-268: In WorkflowTracker.resolveGate, only consume the
idempotency entry for gates that are actually parked by checking the node
snapshot state is WAITING_APPROVAL before adding to resolvedGates. Keep the
resolvedGates key until after backend.resolveWorkflowGate(runId, nodeName,
approved, error) succeeds, and if resolution fails, do not leave the gate marked
resolved. Use the existing resolveGate, resolvedGates, gateTimers, and
backend.resolveWorkflowGate symbols to update the flow so early
approveGate/rejectGate calls on PENDING nodes do not promote successors
prematurely.
- Around line 213-225: In WorkflowTracker.promoteOutcome, the promotedNodes
dedupe is applied before the promotion side effects, so if enterGate(...) or
createDeferredJobFor(...) throws the node remains half-promoted and future
retries will be blocked. Update the logic around the GateKey add check to roll
back the dedupe entry when promotion fails, or explicitly mark the node failed
before returning, so subsequent outcome handling can retry or fail cleanly.
Focus on the promoteOutcome flow and the enterGate/createDeferredJobFor paths.

---

Outside diff comments:
In `@crates/taskito-java/src/workflows/mod.rs`:
- Around line 571-580: The workflow plan serialization currently drops the
run-level queue default, so deferred jobs later built by WorkflowTracker can’t
recover the effective queue and may use the wrong one. Update getWorkflowPlan to
persist or expose the effective queue for deferred nodes, using
PlanNode.queueOrDefault() or an equivalent resolved queue field instead of only
serializing the per-step queue. Make sure the plan metadata includes enough
information for WorkflowTracker to enqueue deferred successors with the same
default queue that was active at submit time.